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(54) Non supervisor-mode cross-address space dynamic linking. 

(57) In a network of object oriented distributed 
systems, a plurality of program code managers, 
each having access to a plurality of program 
code segment objects, a plurality of address 
space managers, each having access to a 
plurality of address space objects having linked 
program segment and symbol address infor- 
mation, and a plurality of trusted third party 
authentication managers are provided, thereby 
allowing a client process executing in non- 
supervisor mode to be able to dynamically link a 
program segment to either another program 
segment in another address space or a process 
in either another address space or the client's 
address space, without compromising the sec- 
urity of the systems. 
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BACKGROUND OF THE INVENTION 

1. Field of the Invention: 

The present invention relates to the fields of dis- 
tributed computer systems, distributed operating sys- 
tem, and object oriented programming. More particu- 
larly, the present invention relates to cross address 
space dynamic linking of program code segments at 
program start, and dynamic linking of a program code 
segment to a process. 

2. Background: 

Today, most modern computer systems with vir- 
tual memory systems and multiprocessing allow more 
than one address space to be active at one time. The 
central processing unit (CPU) or units switch between 
the active address spaces at high speed. An address 
space is a range of logical addresses representing a 
range of memory locations within which programs 
and data may be stored. 

Address spaces form a layer of security protec- 
tion for the computer system. A process executing in 
non-supervisor mode in one address space typically 
cannot access another process executing in another 
address space, except through special means provid- 
ed by the operating system. This prevents a process 
in one address space whose security has been com- 
promised from damaging the entire computer system. 
A process is an instance of a program in execution. 

On the other hand, operations performed by a 
process in supervisor mode are by definition secure. 
Entering supervisor mode before a process is allowed 
to perform operations on an address space therefore 
ensures that system security is not compromised. 
Thus, traditional operating systems typicality require 
a process to enter supervisor mode before it can dy- 
namically load a program into an address space. 
Loading a program into an address space involves ob- 
taining memory from the operating system and asso- 
ciating the binary code of a program with the memory 
obtained. 

If the program consists of several unconnected 
segments of binary code, and the segments of binary 
code have not been statically linked together before 
the program is loaded into the address space, the 
segments of binary code will have to be dynamically 
linked together after they are loaded into the address 
space, before execution of the program can be start- 
ed. Typically, rf the program has been statically 
linked, then only one "segment" of binary code is 
loaded, otherwise, more than one segment of binary 
code is loaded. 

Traditionally, operating systems also require the 
process to perform the dynamic linking in supervisor 
mode or within the address space where the program 
code to be linked is located. Linking segments of bi- 



nary code involves resolving references in one seg- 
ment of binary code which require addresses in the 
other. 

Additionally, a dynamically linked program typi- 

5 cally requires an initialization function to be called be- 
fore starting execution. The initialization sets up the 
initial conditions required by the linked program's pro- 
gramming language run time system, and is neces- 
sary for the linked program to function correctly. 

10 Supervisor mode cross address space dynamic 

linking was originally part of the Multix operating sys- 
tem and TENIX. Because it was perceived to involve 
excessive overhead, supervisor mode cross address 
space dynamic linking was dropped from most oper- 

15 ating systems, until it was reintroduced in UNIX™ 
System V (Unix™ is the registered trademark of Unix 
Laboratory). Today supervisor mode cross address 
space dynamic linking is offered in OSF/1. Forfurther 
description of supervisor mode cross address space 

20 dynamic linking under these operating systems, see 
E.L Organick, The Multics System; An Examination of 
Its Structure , MIT Press, 1972, D.L. Murphy, Storage 
organization and management in TENIX , Proceed- 
ings of the Fall Joint Computer Conference, AFIPS, 

25 1972, J.Q. Arnold, Shared Libraries on Unix System 
V, Summer Conference Proceedings, USENIX Asso- 
ciation, 1986, and L.W. Allen, H.G. Singh, K.G. Wal- 
lace, and M.B. Weaver, Program Loading in OSF/1 , 
Proceedings of the USENIX Winter 1991 Conference, 

30 1991. 

Non-supervisor mode dynamic linking within an 
address space was made available on the operating 
system SunOS 4.1, offered by the assignee of the 
present invention, Sun Microsystems, Inc. of Moun- 

35 tain View, California (Sun™ is a registered trademark 
of Sun Microsystems, Inc.). Under SunOS 4.1 , a proc- 
ess without having to enter supervisor mode first, can 
dynamically linked shared libraries into itself when it 
starts up. Because the non-supervisor mode dynam- 

40 ic linking is limited to linking shared libraries to the 
process itself, therefore a process with compromised 
security can only affect the address space within 
which the process is executing. Forfurther descrip- 
tions of dynamic linking under SunOS 4.1, see R.A. 

45 Gingell, M. Lee, X.T. Dang and M.S. Weeks, Shared 
Libraries in SunOS . Proceedings of USENIX Summer 
1987 Conference, 1987. A similar procedure is used 
for dynamic linking on UNIX™ System V Release 4. 
see System V Application Binding Interface , Prentice 

50 Hall. 1991. 

While limiting dynamic linking across address 
spaces to processes executing in supervisor mode or 
processes within the address space where the pro- 
gram code to be linked is located has the benefit of 

55 preventing a compromised process from compromis- 
ing the entire system, it severely limits the extent to 
which dynarr ic linking can be used to securely modify 
execution behavior of a process. Thus, it is desirable 
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to allow a process executing in non-supervisor mode 
to perform dynamic linking across address spaces 
without compromising system security. 

SUMMARY OF THE INVENTION s 

It is therefore the object of the present invention 
to provide the ability of cross address space dynamic 
linking, to processes executing in non-supervisor 
mode without compromising the security of the com- to 
puter system. 

It is the object of the present invention to provide 
the ability of cross address space dynamic linking of 
a program segment to a process as well as program 
segments at program start 15 

Under the present invention, these and other ob- 
jects are achieved by providing a first program code 
manager to provide a first program code segment in 
a secure manner to a first process executing in non- 
supervisor mode in a first address space, and an ad- 20 
dress space manager for mapping the first program 
code segment into a second address space, linking 
the first program code segment to either a second 
program code segment if the second address space 
is a new address space with no executing process or 25 
a second process if the second address space has an 
executing process. 

For the case where the second address space is 
a new address space with no executing process, the 
present invention also provides a second program 30 
code manager to provide the second program code 
segment in a secure manner to the first process. The 
address space manager is also used to provide ac- 
cess to the second address space in a secure manner 
to the first process, and for mapping the second pro- 35 
gram code segment into the second address space. 
The first process creates a code table and a symbol 
address table before linking the first and second pro- 
gram code segments. 

For the case where the second address space 40 
has at least one executing process, the address 
space manager is also used to provide a code table 
for identifying the first program code segment as not 
being linked in the second process, and to provide 
symbol address information for generating a symbol 45 
address table. The symbol address table is used for 
linking the first program code segment with the sec- 
ond process in the second address space. 

Execution of the second program code segment 
or the second process linked with the first program so 
code segment is started by transferring control to a 
starting address within the second address space. 
More specifically, execution of the second process 
linked with the first program code segment is started 
by starting a new t hread of execution and transferring 55 
control to the starting address of an initialization func- 
tion in the second address space. The initialization 
function is located by the first process using the sym- 



bol address table. 

Additionally, in the preferred embodiment of the 
present invention, a third party authentication man- 
ager is provided for authorizing the first process to be 
provided with the first and second program code seg- 
ments, and the second address space. The code ta- 
ble is located at a predetermined location of the ad- 
dress space manager. 

Furthermore, in their presently preferred form, 
the first and second processes, the first and second 
program code segments, the first and second ad- 
dress spaces, the first and second program man- 
agers, the address space manager and the third par- 
ty authentication manager are implemented in an ob- 
ject oriented manner. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The objects, features and advantages of the 
present invention will be apparent from the following 
detailed description of the preferred embodiment of 
the invention with references to the drawings in 
which: 

Figure 1 shows a physical view of the hardware 
elements of a network of computer systems that in- 
corporates the teachings of the present invention. 

Figure 2 shows a logical view of the software ele- 
ments of one of the computer systems illustrated in 
Figure 1. 

Figure 3 shows a logical view of a client process 
and a plurality of objects on the network of computer 
systems illustrated in Figure 1. 

Figure 4 shows a logical view of an address 
space manager, an address space object, a program 
code manager, a program code segment object, and 
an authentication manager of the present invention 
on the network of computer systems illustrated in Fig- 
ure 1. 

Figure 5 shows a logical view of an address 
space manager, an address space object, a name 
context object, a code table object and a symbol ad- 
dress table object of the present invention on the net- 
work of computer systems illustrated in Figure 1, as 
an alternate approach to provide program code seg- 
ment linkage and name to address information for the 
address space. 

Figures 6 illustrates the method of the present 
invention for non-supervisor mode cross address 
space dynamic linking of program code segments at 
program start up. 

Figures 7 illustrates the method of the present 
invention for non-supervisor mode cross address 
space dynamic linking of a program code segment to 
a process. 

NOTATIONS AND NOMENCLATURE 

The detailed description which follows is present- 
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ed largely in terms of program procedures executed 
on a network of computers. These procedural de- 
scriptions and representations are the means used 
by those skilled in the art to most effectively convey 
t he su bstance of t heir work to ot hers skilled in t he art. 

A procedure is here, and generally, conceived to 
be a self-consistent sequence of steps leading to a 
desired result. These steps are those that require 
physical manipulations of physical quantities. Usual- 
ly, though not necessarily, these quantities take the 
form of electrical or magnetic signals capable of being 
stored, transferred, combined, compared, and other- 
wise manipulated. It proves convenient at times, prin- 
cipally for reasons of common usage, to refer to these 
signals as bits, values, elements, sym boils, objects, 
characters, terms, numbers, or the like. It should be 
borne in mind, however, that all these and similar 
terms are to be associated with the appropriate phys- 
ical quantities and are merely convenient labels ap- 
plied to these quantities. 

Further, the manipulations performed are often 
referred to in terms, such as adding or comparing, 
which are commonly associated with mental opera- 
tions performed by a human operator. No such capa- 
bility of a human operator is necessary, or desirable 
in most cases, in any of the operation described here- 
in which form part of the present invention; the oper- 
ations are machine operations. Useful machines for 
performing the operations of the present invention in- 
clude general purpose digital computers or other sim- 
ilar devices. In all cases, it should be borne in mind 
the distinction between the method operations in op- 
erating a computer and the method of computation it- 
self. The present invention relates to method steps for 
operating a computer in processing electrical or other 
physical signals to generate other desired physical 
signals. 

The present invention also relates to apparatus 
for performing these operations. This apparatus may 
be specially constructed for the required purposes or 
it may comprise a general purpose computer as selec- 
tively activated or re-configured by a computer pro- 
gram stored in the computer. The procedures pre- 
sented herein are not entirely related to any particular 
computer or other apparatus. In particular, various 
general purpose machines may be used with proce- 
dures written in accordance with the teaching herein, 
or it may prove more convenient to construct more 
specialized apparatus to perform the required meth- 
od steps. The required structure for a variety of these 
machines will appear from the description given be- 
low. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

A method and apparatus for a process executing 
in a non-supervisor mode to perform cross address 
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space dynamic linking is disclosed. In the following 
description for purposes of explanation, specific num- 
bers, materials and configurations are set forth in or- 
der to provide a thorough understanding of the pres- 
5 ent invention. However, it will be apparent to one skil- 
led in the art that the present invention may be prac- 
ticed without the specific details. In other instances, 
well known systems are shown in diagrammatical or 
block diagram form in order not to obscure the pres- 
to ent invention unnecessarily. 

Referring now to Figure 1, a block diagram illus- 
trating a physical view of a network of computer sys- 
tems that incorporates the teachings of the present 
invention organized by its hardware elements is 

is shown. The network of computer systems 10 com- 
prises at least one computer system 12a or 12b. If 
more than one computer system 12a and 12b are em- 
ployed, the computer systems 12a and 12b are cou- 
pled to each other through a network 22. Each corrv 

20 puter system 12a or 12b comprises at least one cen- 
tral processing unit (CPU) 14a or 14b, a memory unit 
16a or 16b, a mass storage unit 18a or 18b and an in- 
put/output (I/O) device 20a or 20b. The characteris- 
tics of these hardware elements on each of the com- 

25 puter systems 12a or 12b, such as speed, size, may 
differ from each other. These hardware elements are 
- those typically found in most general purpose com- 
puter systems and almost all special purpose comput- 
er systems. In fact, the several hardware elements 

30 contained within each of the computer system 12a 
and 12b are intended to be representative of this 
broad category of data processing systems. Particu- 
lar examples of suitable data processing systems to 
fill the role of these computer systems 12a and 12b 

35 include computer systems manufactured by Sun Mi- 
crosystems, Inc., Mountain View, California. Other 
computer systems having like capabilities may of 
course be adapted in a straight forward manner to 
perform the functions described below. 

40 Referring now to Figure 2, a block diagram illus- 

trating a logical view of one of the computer systems 
illustrated in Figure 1 organized by its system soft- 
ware is shown. The system software 30 comprises an 
operating system 32. a file system 34, and at least 

45 one language compiler 36. Operating system 32 pro- 
vides well known operating system services, in par- 
ticular, network virtual memory management with a 
coherent page caching algorithm,, and an object ori- 
ented interface for securely mapping files into ad- 

50 dress spaces on behalf of a process executing in non- 
supervisor mode. File system 34 provides well known 
file system services such as open, close, read and 
write. Language compiler 36 provides well known 
compiler services such as parsing and code genera- 

55 tion, and well known runtime library services such as 
mathematical functions and string manipulations. Ap- 
plications 38 executing on the computer system util- 
ize the underlying system services offered by system 

4 



7 



EP 0 547 759 A2 



8 



software 32 - 36. 

These system software elements, except the op- 
erating system, are those typically found in most gen- 
eral purpose computer systems and almost all special 
purpose computer systems. In fact, the several non- 
operating system system software elements con- 
tained within each of the computer system are intend- 
ed to be representative of this broad category of non- 
operatmg system system software. Additionally, the 
system software used on each of the computer sys- 
tem may be different provided they offer equivalent 
functions and capable of communicating with each 
other. For further descriptions of operating system 
with network vrtual memory management having a 
coherent page caching algorithm, see Yousef Khalidi, 
Hardw a re So poor t for Distributed Operating Sys- 
tems . KhD I Georgia Institute of Technology, 
1988 

Kefernng ncm to Figure 3, a block diagram illus- 
trating a ksgtcM ne« of a dient process, an object 
manager and « (vuralty of objects on the network of 
computer sy*tem» •ustrated in Figure 1 is shown. 
Shown n fkgur* ) a a d>ent process 42, an object 
manager 44 and a plurality of objects, 46, 47, 48. A 
client pruce%» 42 m a process that uses an object 46, 
47 or 48. Eatn uOyocL 46. 47 or 48 is a component 
comprising data and operations which can be invoked 
to manipulate the data. Possession of an object 46, 
47 or 48 «nr>« nght to access the object 46, 47 or 
48. The opera: ons are invoked on the object 46, 47 
or 48 by scndng cats to the object 46, 47 or 48. An 
object manage* 44 is an address space in which the 
code for the objects operations reside. Each object 
46, 47 or 48 has an object type. The object type de- 
fines the object operations that can be performed on 
objects 46. 47 and 48 of that particular object type. 
The object operations are implemented independent 
of the objects 46. 47 or 48 themselves. Additionally, 
the objects 46. 47. and 48 are organized into a class 
hierarchy according to their object types, thereby al- 
lowing one object type organized into a subclass to in- 
herit the object operations defined and implemented 
for other object types organized in the super class. 
Each object 46. 47 or 48 is a class instance of a class. 
For further description on object-oriented design and 
programming techniques, see B. Meyer, Object-ori- 
ented Software Construction , (Prentice Hall, 1988). 

It will be appreciated that the network of comput- 
er systems illustrated in Figure 1 may comprise a va- 
riety of client processes, object managers, and ob- 
jects. The client process 42, the object manager 44 
and the objects 46, 47 and 48 shown in Figure 3 are 
intended to be representative of a broad category of 
these client processes, object managers, and ob- 
jects. 

Referring now to Figure 4, a block diagram illus- 
trating an address space manager, an address space 
object, a program manager, a program code segment 



object, and an authentication manager of the present 
invention is shown. Shown is a program code man- 
ager 54 providing an object oriented interface to a cli- 
ent process 52 for accessing a program code seg- 

5 ment object 60. The program code segment object 60 
comprises executable binary code of a program or a 
program segment. In its presently preferred form, the 
program code manager 54 validates the client's ac- 
cess authority using a trusted third party authentica- 
te tion manager 56. For further descriptions of trusted 
third party authentication manager, see Michael Bur- 
rows, Martin Abadi, and Roger Needham, A Logic of 
Authentication , ACM Transactions on Computer Sys- 
tems, 8(1), 1990, pp 18- 36 . 

15 Also shown in Figure 4 is an address space man- 

ager 58 providing an object oriented interface to the 
client process 52 for obtaining an address space ob- 
ject 62. Similarly, in its presently preferred form, the 
address space manager 58 validates the client's ac- 

20 cess authority using the trusted third party authenti- 
cation manager 56. 

The address space object 62 comprises an ad- 
dress space (not shown) and provides an object ori- 
ented interface for performing limited operations on 

25 the address space on behalf of client processes exe- 
cuting in non-supervisor mode. The limited opera- 
tions comprise an operation for returning a list of 
memory objects mapped into the address space and 
the corresponding base addresses for the memory 

30 objects, and an operation of mapping a program code 
segment and/or a group of data into the address 
space, producing a memory object corresponding to 
the mapped memory. During a mapping operation, 
the program code and/or the group of data is inserted 

35 into the address space in bulk, and the addresses of 
the address space is associated with the program 
code and/or data. As described earlier, during the op- 
eration of linking, references in one program code 
segment which require addresses in another program 

40 code segment are resolved. 

Additionally, during a mapping operation, symbol 
address information about a program segment is ob- 
tained from the program segment by accessing the lo- 
cations where the program segment is deposited. The 

45 symbol address information is used to generate a 
symbol address table comprising name to address 
cross reference entries for the address space. The 
generated symbol address table is in turn used to fa- 
cilitate linking a program code segment to another 

so program code segment or a process, which wiii be dis- 
cussed in further detail later. The symbol address in- 
formation comprises names and addresses of func- 
tions and data in the program segment being map- 
ped. 

55 The limited operations further comprise an oper- 

ation for obtaining linked program segment informa- 
tion of the address space from the address space's 
code table (not shown). The linked program segment 
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information is used to determine whether a program 
code segment is already linked to a process in the ad- 
dress space, which will be described in further detail 
later. The code table comprises entries for each linked 
program code segment for the address space. Each 
entry comprises the linked program code segment's 
base address, size, and name of the mapped file. Ad- 
ditionally, the code table comprises a semaphore for 
locking the code table when the code table is in use. 
The operations for togging a program code segment 
as being inked in the address space, removing the log 
entries, confirming whether a program code segment 
is already linked in the address space, setting and 
clearing the semaphore are all performed by mapping 
the memory object associated with the code table 
into the address space and operating upon the mem- 
ory there. In their presently preferred form, the code 
table is located at a predetermined location in the ad- 
dress space 62. 

It will be appreciated that the network of comput- 
er systems illustrated in Figure 1 may comprise a va- 
riety of client processes, program code managers, 
program code segment objects, authentication man- 
agers, address space managers, and address space 
objects. The client process 52, the program code 
manager 54, the authentication manager 56, the ad- 
dress space manager 58, the program code segment 
object 60, and the address space object 62 shown in 
Figure 4 are intended to be representative of a broad 
category of these client processes, object managers, 
and objects. 

Referring now to Figure 5, a block diagram illus- 
trates an alternate approach for accessing the limited 
program segment and the symbol address informa- 
tion is shown. Shown is a name context object 64 pro- 
viding an object oriented interface for accessing the 
linked program segment information from a code ta- 
ble object 66 and the symbol address information 
from a symbol address table object 68 on behalf of a 
client process executing in non-supervisor mode. In- 
stead of being located at a pre-determined location of 
the address space, the code table is located in the 
code table object 66. Similarly, instead of obtaining 
the symbol address information directly from the pro- 
gram segment being mapped and generating the 
symbol address table, the symbol address informa- 
tion is maintained in the symbol address table object 
68. Under this approach, the address space manager 
52 also supports operations for accessing a name 
context in the name context object 64. 

The name context object 64 comprises a name 
context (not shown) having name to object cross ref- 
erence entries for the address space. The name con- 
text object 64 supports operations for binding an ob- 
ject to a name, removing the binding to a name, and 
resolving a name to an object. The code table object 
66 and the symbol address tab'e object 68 are ob- 
tained from the name context object 64, by resolving 



well known names to these objects. 

Unlike the previously described approach, the 
code table does not have a semaphore. The code ta- 
ble is removed when accessed by a client process, 

5 thereby preventing the code table from being used by 
another process while it is being used. The code table 
object 66 supports operations for logging a program 
code segment as being linked in the address space, 
removing the log entries and confirming whether a 

10 program code segment is already linked in the ad- 
dress space. 

The symbol address table comprises name to ad- 
dress cross reference entries for the address space. 
Additionally, the symbol address object 68 supports 

15 operations for cross referencing a name to an ad- 
dress, removing a name to address cross reference, 
and resolving a name to an address within the ad- 
dress space. 

Referring now to Figure 6, a flow chart illustrat- 

20 ing the method of the present invention for non-su- 
pervisor mode cross address space linking of pro- 
gram code segments at program start up is shown. 
Initially, the client process obtains a new address 
space object with no executing process from an ad- 

25 dress space manager, and obtains the program code 
segment objects from one or more program code 
managers, blocks 72 and 74. As described earlier, in 
the preferred embodiment, the client process* au- 
thority to obtain the new address space object and 

30 the program code segment object is validated using 
a trusted third party authentication manager. 

The client process then constructs a code table 
and a symbol address table for the address space, 
block 76. The client process also updates the name 

35 context if t he name context approach is used . The cli- 
ent process then maps the program code segments 
into the new address space and into its own address 
space, and links them together relative to addresses 
in the new address space, block 78. The client proc- 

40 ess deports the code table in the address space if the 
name context approach is not used. After linking the 
program code segments, the client process starts 
execution of the linked program by transferring con- 
trol to the starting address of the linked program in 

45 the new address space, block 80. 

Referring now to Figure 7, a flow chart illustrat- 
ing the method of the present invention for non-su- 
pervisor mode cross address space dynamic linking 
of a program segment to a process is shown, initially, 

50 the client process obtains an address space with an 
executing process, block 84. The client process then 
obtains the code table for the address space, block 
88, with or without obtaining a name context first, de- 
pending whether the code table is located in a prede- 

55 termined location of the address space manager or in 
a code table object. Similarly, as described earlier, in 
the preferred embodiment, the client process* au- 
thority to obtain the address space, the code table, 
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and the name context If used, is validated using a 
trusted third party authentication manager. 

If the code table indicates that the program code 
segment has not been linked in the address space, 
the client then obtains the program code segment ob- s 
jectfrom a program code manager, block 92, and gen- 
erates the symbol address table for the address 
space or obtains the symbol address table if the name 
context approach is used, block 94. Likewise, as de- 
scribed earlier, in the preferred embodiment, the cli- 10 
ent process* authority to obtain the program code 
segment object is validated using a trusted third party 
authentication manager. 

The client process then maps the program code 
segment into the address space and into its own ad- 15 
dress space and links the program code segment rel- 
ative to addresses in the executing process, blocks 
96 and 98. Upon linking the program code segment 
to the executing process, the client process then lo- 
cates the initialization function of the program code 20 
segment, block 100. Upon locating the initialization 
function, the client process starts a new thread of 
execution for the executing process linked with the 
program code segment and transfers control to the 
starting address of the initialization function. 25 

It will be appreciated that the step of obtaining the 
code table object of the address space object and de- 
termining whether the program code segment is al- 
ready linked in the address space, blocks 88 and 90, 
may be skipped if the client process knows whether 30 
the program code segment is linked or not. Similarly, 
the step of obtaining the address space object, block 
86, may also be skipped if the client process has ob- 
tained the address space object 

It will also be appreciated that the method of the 35 
present invention for non-supervisor mode cross ad- 
dress space dynamic linking of a program segment to 
a process illustrated in Figure 7 also may be applied 
to dynamically linking a program segment to the client 
process itself. The target address space is the client 40 
process* own address space and the target process 
is the client process itself. 

It will be further appreciated that the present in- 
vention does not have to be practiced in an object ori- 
ented manner. The elements of the present invention 45 
may be adapted to their non-object oriented equiva- 
lents, and these non-object oriented equivalents be 
accessed using well known approaches such as han- 
dles. 

While the present invention has been described so 
in terms of a presently preferred embodiment, those 
skilled in the art will recognize that the invention is not 
limited to the embodiment described. The method 
and apparatus of the present invention can be prac- 
ticed with modification and alteration within the spirit 55 
and scope of the appended claims. The description is 
thus to be regarded as illustrative instead of restric- 
tive on the present invention. 



Claims 

1. In a network of computer systems comprising at 
least one central processing unit (CPU) execut- 
ing a plurality of processes in a plurality of ad- 
dress spaces, wherein each of said processes 
being executed in a selected one of a supervisor 
and a non-supervisor mode of execution, a meth- 
od for a process executing in said non-supervisor 
mode in a first address space to dynamically link 
a first program code segment to a selected one 
of a second program code segment and a second 
process in a second address space, without com- 
promising said computer systems' security, said 
method comprising the steps of: 

a) obtaining said first program code segment 
and a handle of said second address space 
from a first program code manager and said 
an address space manager respectively in a 
secure manner, 

b) mapping said first program code segment 
into said first and second address spaces us- 
ing said address space manager; 

c) linking said first program code segment to 
said selected one of said second program 
code segment and said second process using 
said second address space's handle; and 

d) transferring execution control to a start ad- 
dress in said second address space. 

2. The method as set forth in Claim 1, wherein, 

said second address space is a new ad- 
dress space with no executing process; 

said step a) further comprises obtaining 
said second program code segment from a sec- 
ond program code manager in a secure manner, 
creating a code table comprising program code 
segment linkage information for said second ad- 
dress space, obtaining names and correspond- 
ing addresses information from said first and sec- 
ond program code segments, and creating a sym- 
bol address table comprising said names and 
corresponding addresses for said second ad- 
dress space; and 

said step b) further comprises mapping 
said second program code segment into said sec- 
ond address space using said address space 
manager; and 

said step c) comprises linking said first 
program code segment to said second program 
code segment using said second address 
space's handle and said symbol address table. 

3. The method as set forth in Claim 2, wherein, said 
secure manner in step a) comprises obtaining au- 
thorizations from a third party authentication 
manager when obtaining said first and second 
program code segments and said second ad- 
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dress space's handle from said first and second 
program code managers and said address space 
manager respectively. 

4. The method as set forth in Claim 2, wherein, said s 
first process, said first and second program code 
segments, said first and second address spaces, 
said first and second program code managers, 
said address space manager, and said third party 
authentication manager, are implemented in an 10 
ob)ect oriented manner. 

5. The method as set forth in Claim 2, wherein, said 
f est and second program code managers are the 
same program code manager. is 

6. The method as set forth in Claim 1, wherein, 

ta«3 second address space is an existing 
adefress space having at least said second proc- 
ess, and said test program code segment is cur- 20 
rentty not linked 10 said second process; 

*a«s step a) further comprises obtaining 
and upcuttng m code table comprising program 
code segment Inkage information for said sec- 
ond addn?** space using said second address 25 
space • handle, obtaining and updating a symbol 
addies* tabte comprising names and cor re- 
sponding addresses for said second address 
space us«tg said second address space's handle 
if said symbol address table is maintained, other- 30 
wise, obtan*vg said names and corresponding 
addresses information from said first program 
segment and said said second process, and cre- 
ating said symbol address table for said second 
address space. 35 

said step c) comprises linking said first 
program code segment to said second process 
using said second address space's handle and 
said symbol address table; and 

said step d) further comprises locating an 40 
initialization function in said second address 
space using said symbol address table, and said 
transfer of control to a start address in said sec- 
ond address space comprises calling said initial- 
ization function. 45 

7. The method as set forth in Claim 6, wherein, said 
secure manner in said step a) comprises obtain- 
ing authorizations from a third party authentica- 
tion manager when obtaining said first program 50 
code segment and said second address space's 
handle from said first program code manager and 
said address space manager respectively. 



8. The method as set forth in Claim 6, wherein, 

said first and second processes, said first 
program code segment, said first and second ad- 
dress spaces, said first program code manager, 



55 



said address space manager, and said third party 
authentication manager, are implemented in an 
object oriented manner. 

9. The method as set forth in Claim 6, wherein, said 
first and second processes are the same proc- 
ess, and said first and second address spaces 
are the same address space. 

10. In a network of computer systems comprising at 
least one central processing unit (CPU) execut- 
ing a plurality of processes in a plurality of ad- 
dress spaces, wherein each of said processes 
being executed in a selected one of a supervisor 
and a non-supervisor mode of execution, an ap- 
paratus for a process executing in said non-su- 
pervisor mode in a first address space to dynam- 
ically link a first program code segment to a se- 
lected one of a second program code segment 
and a second process in a second address 
space, without compromising said computer sys- 
tems' security, said apparatus comprising: 

a) a first program code manager coupled to 
said CPU for providing said first program code 
segment to said first process in a secure man- 
ner; and 

b) an address space manager coupled to said 
CPU for providing a handle of said second ad- 
dress space to said first process in a secure 
manner, and for mapping said first program 
code segment into said first and second ad- 
dress spaces at the request of said first proc- 
ess; 

said first process linking said first program 
code segment to said selected one of said second 
program code segment and said second process 
using said second address space's handle after 
obtaining said first program code segment and 
said second address space's handles, and map- 
ping said first program code segment into said 
first and second address spaces; 

execution of said selected one of said sec- 
ond program code segment and said second 
process linked with said first program code seg- 
ment being started when execution is transferred 
to a start address in to said second address 
space. 

11. The apparatus as set forth in Claim 10, wherein, 

said apparatus further comprises c) a sec- 
ond program code manager coupled to said CPU 
for providing said first process with said second 
program code segment in a secured manner if 
said second address space is a new address 
space with no executing process; 

said address space manager is also used 
for mapping said second program code segment 
into said first and second address spaces; 
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said first process links said first program 
code segment to said second program code seg- 
ment using said second address space's handle 
and a symbol address table comprising names 
and corresponding addresses of said second ad- s 
dress space; 

said mapping and linking being performed 
after said first process constructs said symbol 
address table and a code table comprising pro- 
gram code segment linkage information of said 10 
second address space. 

12. The apparatus as set forth in Claim 11, wherein, 
said apparatus further comprises d) a third party 
authentication manager for authorizing said first 15 
process to be provided with said first and second 
program code segments and said second ad- 
dress space's handle from said first and second 
program code managers and said address space 
manager respectively. 20 



13. The apparatus as set forth in Claim 11, wherein, 
said first process, said first and second program 
code segments, said first and second address 
spaces, said first and second program code man- 
agers, said address space manager, and said 
third party authentication manager, are imple- 
mented in an object oriented manner. 



second process linked with said first program 
segment by calling an initialization function in 
said second address space, said initialization 
function being located using said symbol address 
table. 

16. The apparatus as set forth in Claim 15, wherein, 
said apparatus further comprises d) a third party 
authentication manager for authorizing said first 
process to be provided with said first program 
code segment and said second address space's 
handle by said first program code manager and 
said address space manager respectively. 

17. The apparatus as set forth in Claim 15, wherein, 
said first and second processes, said first 

program code segment, said first and second ad- 
dress spaces, said first program code manager, 
said address space manager, and said third party 
authentication manager, are implemented in an 
object oriented manner. 

18. The apparatus as set forth in Claim 15, wherein, 
said first and second process are the same proc- 

25 ess, and said first and second address space are 

the same address space. 

19. An improved network of computer systems com- 
prising at least one central processing unit (CPU) 
executing a plurality of processes in a plurality of 
address spaces, wherein each of said processes 
being executed in a selected one of a supervisor 
and a non-supervisor mode of execution, said im- 
provement comprises a process executing in said 
non-supervisor mode in a first address space us- 
ing an improved method to dynamically link a first 
program code segment to a selected one of a sec- 
ond program code segment and a second proc- 
ess in a second address space, without compro- 
mising said computer systems' security. 



14. The apparatus as set forth in Claim 11, wherein, 30 
said first and second program code managers 
are the same program code manager. 

15. The apparatus as set forth in Claim 10, wherein, 

said second address space is an existing 35 
address space having said second process, said 
first program code segment being not linked to 
said second process; 

said first process obtains and updates a 
code table comprising program code segment 40 
linkage information for second second address 
space using said second address space's han- 
dle; 

said first process obtains and updates a 
symbol address table comprising names and cor- 45 
responding addresses for said second space us- 
ing said second address space's handle if said 
symbol table is maintained, otherwise, said first 
process obtains said names and corresponding 
addresses from said first program code segment so 
and said second address space, and creates said 
symbol address table for said second address 
space; 

said first process links said first program 
code segments to said second process using said 55 
second address space's handle and said symbol 
address table; 

said first process transfers control to said 
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